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REMARKS/ARGUMENTS 

Claims 1-9, 11-66 are pending in this application. Claims 33-34 are amended to correct 
informalities and claims 41-66 are added. Support for the subject matter in claims 41-66 is 
found in the specification, for example, beginning at the first paragraph on page 9. No new 
matter is added. Applicant respectfully requests reconsideration of the application in view of the 
above amendments and following remarks. 

Matters of Form 

The Office Action rejects claims 33 under 35 U.S.C §112, second paragraph. Applicant 
has amended claim 33 to obviate this rejection. Additionally, Applicant has amended claim 34 
to correct an informality. 

Patentable Subject Matter 

The Office Action rejects claims 1, 3-9, 11-26, 28, 31, 37 and 38 under 35 U.S.C. §102(e) 
over Talati, et al. (U.S. Patent No. 5,903,878). This rejection is respectfully traversed. 

As discussed below, Talati does not disclose or suggest at least the feature of 
"transmitting a query for said authorization number over said network from said third party 
contractor location to said consumer location", as recited in Applicant's independent claim 1 and 
as similarly recited in Applicant's independent claims 9, 17, 22, 33-38 and in added claims 51- 
66. 

Additionally, Talati does not disclose or suggest at least the feature of initiating a 
communication connection of said network between the consumer location and the third party 
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contractor location, wherein the initiating is performed from the on-line merchant location as 
recited in added dependent claim 41, and generally corresponding features recited in dependent 
claims 42-50 and in dependent claims 52, 54, 56, 58, 60, 62, 64, and 66. 

Talati is directed to a method for seeking approval from a customer of a merchant- 
requested purchase order, by first sending a request for authentication of the customer to a 
transaction administrator or credit authority. Upon authentication of the customer (based on an 
originator ID - OID), the transaction administrator or credit authority then sends a unique 
transaction ID (UTID), the credit card number, specific information regarding the purchase 
request to the customer, for the customer's approval. Upon the customer's comparison of the 
specifics of the original transaction (by the customer) with the specifics of the requested 
transaction (from the merchant), the customer approves or disapproves the merchant-requested 
transaction. Based on the customer's response, the transaction administrator or credit authority 
then grants/rejects the merchant-requested transaction. Therefore, Talati is directed to a 
merchant-request validation scheme, to avoid fraud perpetrated by the merchant. 

Talati's approach is detailed in col. 4, In 53 - col. 5, In 5, for example. An originator 50 
(e.g., customer or client) initiates a transaction comprising a purchase, payment or request for 
information document from the recipient 55 (e.g., merchant). The transaction request from the 
merchant to the transaction administrator 60 includes a unique transaction (UTID) associated 
with the specific transaction request and an originator identity (OID) to identify the originator 50 
(customer) is then sent to the transaction administrator 60. The recipient 55 (merchant) 
generates a request for authentication of the originator 50 (customer) using the OID, UTID to the 
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transaction administrator. The transaction administrator 60 first validates the identity of the 
recipient 55 OID. 

If the OK) is valid, the transaction administrator 60 determines the originator associated 
with the OBD, transmits the transaction request and associated data to the originator 50 
(customer) and requests that the originator 50 (customer) validate the transaction request 
containing the UTID. The originator 50 (customer) validates the transaction bv comparing the 
UTID with a list 100 generated bv the originator (customer) using the UTID associated with each 
transaction generated bv the originator (customer) and notifying the transaction administrator 60 
of the results . (Emphasis added). See col. 5, Ins 7-18, for example. Thus, Talati's process of 
validation is for the "first party" to compare his original request with the third-party forwarded 
request, and notify the third party as to whether the transaction should be permitted or not. 

The above procedure for processing a credit card transaction between a client 50, 
merchant 55 and credit authority (CA) 60 is described in col. 5, In 50- col. 6, In 43, and FIGS. 5- 
6, for example. As stated in col. 6, beginning at line 44, "communication between the client 50 
and the CA 60 guarantees that an unauthorized purchase order is not issued by an unauthorized 
client or merchant 55 and that a merchant does not change the amount on the purchase order 
issued by the client. . . and the verification and validation of the purchase order by the client 
reduces fraudulent transactions.... The UTID ties together all three delivery systems." 

Similarly, for the embodiments described in FIGS. 9-10 of Talati, the client 50 compares 
information on the transaction with the original payment transactions and associated UTIDs. 
The client 50 then notifies the client bank 250 in the banking system 60 with the verdict of the 
validity of the transaction. See col. 7, Ins 47-54, for example. 
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Talati discloses a similar scheme using an email delivery system. See FIGS. 10-16. The 
email system also requires the originator to send a positive or negative validation of the 
transaction to the TA 60. See col. 12, Ins 1-8, for example. 

Since all of Talati's embodiments require the customer to only respond with an approval 
or disapproval of the transaction, one of ordinary skill would know that this approval or 
disapproval does not contain any "protectable" information, such as an account number or 
authorization number or password, etc. 

Therefore, Applicant respectfully submits that Talati does not disclose or suggest at least 
the feature of transmitting a query for said authorization number over said network from said 
third party contractor location to said consumer location, as recited in Applicant's independent 
claim 1 and as similarly recited in Applicant's independent claims 9, 17, 22 and 33-38; or 
initiating a communication connection of said network between the consumer location and the 
third party contractor location, wherein the initiating is performed from the on-line merchant 
location as recited in added independent claim 41 and similarly recited in added independent 
claims 42-50. Thus, Talati does not disclose or render obvious all the features of Applicant's 
independent claims 1, 9, 17, 22 and 33-38, as well as all the features of Applicant's added claims 
41-50. 

Claims 3-8 and 28 depend from claim 1; claims 11-16 depend from claim 9; claims 18-21 
depend from claim 17; and claims 23-26 depend from claim 22. Therefore, for at least the above 
reasons. Applicant respectfully requests the withdrawal of this rejection. 
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The Office Action rejects claims 27, 29, 30 and 32 under 35 U.S.C. § 103(a) over Talati 
and in view of Blonder, et al. (U.S. Patent No. 5,708,422). This rejection is respectfully 
traversed. 

Blonder is directed to a transaction authorization and alert system using a validation 
database 106 containing the customer's mobile communication address 135 (phone, mail, email, 
facsimile). Upon a requested transaction, the request is forwarded to a validation authority 
which compares the submitted request profile to the validation information database and 
forwards an alert or authorization request, with the requested transaction information, to the 
principal or card owner via the mobile conmiunication address contained in the database. Upon 
receipt of the alert/authorization request by the owner, the transaction authorization and alert 
system awaits the owner's approval/disapproval. See FIG. 7 and col. 9, In 34 - col. 10, In 7. 
The owner's approval/disapproval is indicated either orally (if by telephone) or by entering a pre- 
defined code (if by pager/cellphone). See col. 9, ins 18-31, for example. 

Blonder describes an authorization code, however, the authorization code is generated by 
the transaction system, and not by the owner. The authorization code is used by the transaction 
system to notify the retailer of the approval/disapproval status of the transaction. See col. 13, Ins 
23-36, for example. 

Blonder also describes a "pre-approved" confirmation code for the customer during a 
transaction. This confirmation code is randomly generated prior to initiation of a transaction and 
is a priori forwarded to the customer. Upon initiation of the actual transaction, at a merchant's 
place of business, the customer provides the confirmation code to the merchant who then 
forwards it to the transaction processing center. See col. 14, Ins 1-60, for example. 
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In the event an ATM card is used in a commercial transaction, the merchant enters a 
special code into a card reader 101 to initiate the alerting and approval process. Thereafter, the 
card reader 101 retrieves a debit card number, for example, from the magnetic stripe on the back 
of the debit card before prompting the card holder for a secret code (e.g. PIN). It is noted that all 
of these steps disclosed by Blonder are known to be the prior art approach, as discussed in 
Applicant's specification. 

After receiving the PIN, Blonder's card reader 101 then transmits a validation request 
message to validation database 101 as illustrated in FIG. 2. See col. 4, Ins 62- col. 5, In 3, for 
example. The request message includes the card number 201, a requested credit amount 202, a 
merchant code 203, and a validation request 204. When card number 201 is a debit card number, 
it also includes the PIN entered by the card holder. See col. 5, Ins 5-9, for example. 
Accordingly, Blonder' s use of the ATM card requires that the merchant (second party) retrieve 
the PIN entered by the card holder. 

There is no disclosure or discussion in Blonder regarding the transmitting of a query for 
said authorization number over said network from said third party contractor location to said 
consumer location; or initiating a communication connection of said network between the 
consumer location and the third party contractor location, wherein the initiating is performed 
from the on-line merchant location. 

In fact, from the disclosure provided in Blonder, it is evident that other than being able to 
use a database detailing prohibited transactions and owner contact information. Blonder is 
similar to Talati in that a simple approval/disapproval is requested by the transaction authority. 
Therefore, Blonder does not disclose or suggest the subject matter lacking in Talati, as discussed 
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above. Accordingly, Talati and Blonder, individually or in combination, do not disclose or 
suggest all the subject matter recited in the Applicant's independent claims 1, 17, and 22. 

Claims 27 and 29 depend from claim 1; claim 30 depends from claim 17 and claim 32 
depends from claim 22. Accordingly, for at least the reasons discussed above, Applicant 
respectfully requests the withdrawal of this rejection. 

Added claims 41-66 recite subject matter that is not described or suggested in Talati or 
Blonder. Therefore, for at least the same reasons discussed above, Applicant respectfully 
submits that claims 41-66 are allowable over Talati and Blonder. 
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CONCLUSION 



In view of the foregoing remarks, Applicant believes this application is in condition for 
allowance. If, for any reason, the Examiner disagrees, the Examiner is invited to call the 
imdersigned attorney at 202-861-1556 in an effort to resolve any matter still outstanding before 
issuing another action. 

In the event this paper is not timely filed. Applicant petitions for an appropriate extension 
of time. Please charge any fee deficiencies or credit any overpayments to Deposit Account No. 



Date: January 24. 2005 
Washington Square, Suite 1 100 
1050 Connecticut Avenue, N.W, 
Washington, D.C. 20036-5304 
Telephone: 202-861-1500 
Facsimile: 202-861-1783 
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RespectfiiUy submitted, 



BAKER & HOSTETLER LLP 
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